[INTRO MUSIC] In this video, you will watch a
simulated QA job interview and find out exactly why the
candidate's answer worked. One of the most predictable questions in any junior QA interview is how do you write a bug report? The way you answer it tells the interviewer how you think, how you communicate, and whether you are ready to work on a real team. We are joining a first round interview at a midsize software company. Matthew is the QA manager. Manohar is the junior QA
candidate. Thanks for walking me through
your background. Here's my first technical
question. How do you write a bug report? Walk me through your process. Before I document anything, I make sure I can reproduce the defect consistently. A bug report that can't be
reproduced doesn't give the developer enough to work with. Once confirmed, I opened Jira
and write a specific title, not button broken, but something
like checkout button fails to submit form when the post code
field is empty. On Chrome. Then I fill in four sections the
environment, the steps to reproduce, the actual result,
and the expected result. I attach a screenshot or a
screen recording, whatever. It helps. Finally, I assign a severity
level. Does this block a critical task
or is it cosmetic? Can you give me a real example? During a capstone project, I was testing a checkout flow when a user left the post code field blank and selected the submit button. The page refreshed silently. No error message, no feedback. The user had no way of knowing
what went wrong. I documented it in Jira with
exact steps, attached a screen recording, and classified it as
a major defect because it blocked order completion. I logged it with full
reproduction steps so that a developer could pick it up and
action it straight away. That's exactly the kind of
detail we need. Thank you. Now let's look at why Manoj's
answer worked. First, he led with purpose. Manoj's opened by explaining why
reproducibility matters, not just what he does that signals
he understands the impact of his work on the team. Second, he named his tools. Mentioning Jira confirms real transferable experience, and it's a key word that matters in ATS screening. Third, he used precise language terms like severity, level, expected result, and steps to reproduce show fluency, not memorization. Fourth, he had a concrete
example ready. He named the defect, described the user impact, explained his documentation, and confirmed the outcome. One more question. If you found two bugs on the same day, one that breaks the checkout flow completely and one that displays a small UI misalignment on the confirmation page, how would you prioritize them and what would you do first? I would prioritize the checkout
bug immediately. It's a blocker. A user who can't complete a
purchase is a critical failure, so I would document that first. Assign it a critical severity in
Jira and flag it to the developer right away. The UI misalignment is real, but
it doesn't prevent the user from completing a task. I would log it as a minor
defect, so it's tracked, but I wouldn't hold up the release
cycle for it. Severity is about user impact,
what breaks the journey and what's just cosmetic. That's a great distinction. That kind of prioritization
thinking is exactly what we need on the team. Now let's look at why his second
answer landed well. Monarch didn't just recite a
definition of severity levels. He applied them to a real trade
off. He named the user impact,
explaining his reasoning and showed he understands what a
development team actually needs. Clear prioritization so work can
move forward. That is the decision making
pattern QA managers look for in a junior hire. Here is a question for you. Practice your own answer to how
do you write a bug report? Start with purpose. Name your tools. Use precise language and have a
real example ready before you walk into the room. [OUTRO MUSIC]